Released on: July 13, 2008, 2:05 pm

Press Release Author: Alba Spectrum

Industry: Computers

Press Release Summary: Microsoft Dynamics GP add-ons are often written in Great
Plains Dexterity - with new and sometimes alternative GP forms and windows where the
buttons, have scripts and forms themselves have procedures and functions.

Press Release Body: Microsoft Dynamics GP add-ons are often written in Great Plains
Dexterity - with new and sometimes alternative GP forms and windows where the
buttons, have scripts and forms themselves have procedures and functions. These
programming parts are written in Dex Sanscript programming language. Sanscript is
sort of proprietary scripting language, typically you can get Dex programmer from GP
ISV and customization partners, you should check with your Great Plains VAR for
details. When newer Dynamics GP version is released, if you plan to update to it,
you have to take into consideration Dex modification upgrade requirement. In this
small publication w would like to orient you what you could expect from technical
side:

1. Alternative GP Forms. These objects typically require special attention, and let
us explain why. Imagine, you have customized GP Sales Order Processing Entry form
for GP say version 8.0. Now, you plan to upgrade your customization to version
10.0. In version 10.0 GP has (potentially) redesigned some functionality, added and
took off several fields and buttons. Your modification for 8.0 might of be dealing
with the functionality, changed or even not present with version 10.0. This is why
Alternative GP forms are the ones, where Dexterity programmers spends large portion
of upgrading code revision

2. New GP Forms. This is when in your Dex add-on you create the form from scratch.
New forms are typically less sensitive to the version and in majority of the cases
should work fine, if you simply reapply Dex chunk with your add-on to the new
version GP workstation

3. Calling GP Stored Procedures from Dexterity code. If you have your own custom
stored procedure, which you call from Dex code, you need to review its SQL script -
typically check if new version of GP has any changes in the tables, addressed in the
SP. If you call GP original stored procedure, then, you should review GP SDK to see
if new version has the same set of parameters

4. Performance improvement considerations. If you are upgrading from really old
version, especially when you move from old DB platform, such as Ctree or Pervasive
SQL to MS SQL Server, then you can consider offloading some of the Dex logic,
usually found in Dex cursors to custom SQL Stored Procedures, where you can benefit
on the aggregation performance: Select or Insert in SQL would work a way faster than
Dexterity cursor

5. Exotic Sanscript programming examples. In late 1990th we saw such techniques in
Dex software development as inserting scripts into VBA code. This technique allowed
you in one custom add-on to address several GP dictionaries - popular example is GP
Vendor Invoice and Intellisol Advanced Purchase Order Processing. If you have
something like that - we advise you to redesign it, as it is virtually impossible to
debug such code samples


Web Site: http://www.albaspectrum.com

Contact Details: Andrew Karasev, Alba Spectrum http://www.albaspectrum.com
help@albaspectrum.com 1-866-528-0577, 1-630-961-5918, serving Great Plains USA and
Canada nationwide. Local service in Chicago, Houston, Dallas, San Diego. Please
visit our information portal Pegas Planet: http://www.pegasplanet.com . If you need
custom programming for GP, we are happy to help you with Dexterity, eConnect,
VBA/Modifier, SQL Stored Procedures, Crystal Reports. We also provide instant
support to new and existing clients via web sessions for the customers in CA, IL,
WI, NY, FL, IN, MI, TX, GA, NE, NM, AI, NC, SC, OR, WA, DC, DE, PA, VI, AZ, LA